Business Intelligence (BI) generally refers to software tools used to improve business enterprise decision-making. These tools are commonly applied to financial, human resource, marketing, sales, customer and supplier analyses. More specifically, these tools can include: reporting and analysis tools to present information; content delivery infrastructure systems for delivery and management of reports and analytics; data warehousing systems for cleansing and consolidating information from disparate sources; and, data management systems, such as relational databases or On Line Analytic Processing (OLAP) systems used to collect, store, and manage raw data.
There are a number of commercially available products to produce reports from stored data. For instance, Business Objects Americas of San Jose. Calif., sells a number of widely used report generation products, including Crystal Reports™, Business Objects OLAP Intelligence™, and Business Objects Web Intelligence™, and Business Objects Enterprise™. As used herein, the term report refers to information automatically retrieved (i.e., in response to computer executable instructions) from a data source (e.g., a database, a data warehouse, and the like), where the information is structured in accordance with a report schema that specifies the form in which the information should be presented. A non-report is an electronic document that is constructed without the automatic retrieval (i.e., in response to computer executable instructions) of information from a data source. Examples of non-report electronic documents include typical business application documents, such as a word processor document, a spreadsheet document, a presentation document, and the like.
Complex ad-hoc reports can be built with the reporting model described in U.S. Pat. No. 6,831,668, which is incorporated by reference. Using data selected from a semantic layer, reports combine objects that represent data into “zones” of a hierarchy of reporting elements. Each zone implicitly defines a computation context for the data that it contains, based on the hierarchy of its containers and on local information such as the “axes” that govern it and the filters that apply to it. The inclusion of objects in report zones defines complex semantics for the data computed and visualized in the report. Moreover, beside the objects themselves, the user can also define complex report variables or formulas that combine objects together and can also explicitly define or override their computation contexts.
It is not obvious for a report user, even one that has good knowledge of the business semantics of the objects in the Semantic Layer, to really understand the semantics and meaning of report data as it appears in the final layout. Questions such as the following are not easy to answer using state-of-the-art products:                What is the exact definition of the piece of data I'm looking at?        If I'm looking at a value evaluated from a complex expression, what are the values of the sub-expressions used in the computation?        When I'm looking at a measure, does it depend on other dimensions than those shown on the report? If yes, what values have been chosen?        What filters have been applied to my report and did they impact the data I'm looking at?        If I'm looking at an error value, where does the error come from?        What is the original set of database data that led to this computation result?        
Some products can display a formula attached to a cell in the structure of a report. However, this formula does not always clearly indicate which parameters influence the computation of the report value. In addition, the formula does not show the value of the actual parameters that were used to compute the precise value that the user is considering. Some products like Microsoft® Excel® provide an audit capability that helps users understand how a cell was computed from others. But this is limited to a framework where each individual cell can be addressed, regardless of the semantics of the data that it contains, and a cell that is defined as a combination of others uses this addressing system. In a complex Business Intelligence report, report values are defined in a declarative, self-sufficient way, that does not refer to other report values by their “address” but by their data semantics; even if the report is modified and the location of a report value changes, other report values that depend on it still preserve their semantics.
Some Business Intelligence products offer lineage capacities, hence the ability to understand what raw data was used to compute a report, but this applies to a report as a whole; users need to better understand the precise set of data that was used to compute an individual report value.
Other products offer “drill-down” capabilities, which allow a report viewer to get to the next level of detail underlying a computation. However, this capability is limited to navigating dimensions along different levels; it does not help users understand the contribution of various sub-formulas that contribute to the computation of a single value. Some Online Analytical Processing (OLAP) products offer advanced capabilities, but they have significant limitations, such as:                They only provide the requested information for data coming directly from a multidimensional database, not to values computed inside the report;        They only apply to simple reports, such as a unique OLAP grid.        
In view of the shortcomings of the prior art, it would be desirable to provide trusted Business Intelligence in a natural and intuitive way, regardless of the complexity of the data universe and report. In particular, it would be desirable to provide functionality on top of complex reports that contain, for instance, multiple blocks synchronized under sections, and in general an arbitrary nesting of reporting elements combining data from an arbitrary number of data sources and locally computed data, as disclosed in U.S. Pat. No. 6,831,668. In addition, it would be desirable to provide a Business Intelligence technique to support debugging of a report, and in particular to understand why an error value has been computed or how the components of a complex expression contributed to a given value. It would further be desirable to provide a technique to support the definition of a part of a report such that the validity of the data in the report part may be maintained independent from the original report. It would also be desirable to provide a technique to support the definition of a part of a report such that the report part may be defined, displayed, stored, and/or evaluated independent from the remainder of the original report, or may be linked to the original report.